Field
This disclosure relates generally to the field of computer programming. More particularly, but not by way of limitation, it relates to a technique for customizing software applications.
Related Art
Typically a customer acquires a software package from a vendor or receives a software package from another organization and uses the software package within the customer's environment. Often, making some number of changes to the software to change the operation or functionality of the software to meet the needs of the customer's environment better or to add additional functionality to cover additional needs for the customer is desirable. These changes may be to the logic, structures, data definition or capability, or any other alteration in the functionality of the software package solution.
However, a revision or patch or new release of the software package from the supplier may be required or desired. As a result, the customer is left with the issue that the product has changed from the original definition. How can the customer tell what they have changed and what the vendor has changed? How can the customer apply an update to get the fixes and additional functionality of the new version from the supplier but still preserve the customer's customizations? In general, this may be present a difficult problem to the customer. Usually, the solution has been a requirement to redo the customizations on the new release.
Another problem has been a need to have several different sets of customizations of a single environment to satisfy different constituencies using the software package in a shared environment. Each of these constituencies may want to independently (and often in conflict) modify the solution for their specific operation.
This is another difficult problem, usually solved by having independent implementations for the each group, which makes sharing of data difficult and makes the environment more complex.
A number of technologies have attempted solving portions of the problem identified above, but the solutions either do not allow for the continuing inheritance of changes to the software package while also reapplying changes made by the customer or independent customizations being simultaneously used or allow any aspect of the system to be independent of any other. Some of these attempted partial solutions include Shared Libraries/DLLs, Cascading Style Sheets (CSS), and object overlays.
Shared Libraries/DLLs allow for providing alternate definitions, but only for limited aspects of the application that have been predefined. There is no ability to layer definitions, definitions are simply replaced. And, when a definition is replaced by the DLL, no change to the underlying definition will be seen or inherited for the replacement definitions.
CSS allow for the definition of display properties for constructs in the system. They support hierarchical and parallel definition. They do not allow for changing of the fundamental construct definitions of the application but only for display options and characteristics of the objects within the definition. CSS allows reapplication of a definition. However, CSS is not a solution, because CSS does not allow the user to customize the logic or constructs of the system.
Applying an object overlay specifies an alteration to some component or object of the application, preserving the original definition and utilizing the original definition with the overlay definition as part of the definition of the system. Updates provided by the vendor for the component or object are applied to the original definition and are hidden by the object overlay. Therefore, overlaid objects are not updated even if there are changes to the component or object that are not aspects of the object definition that were overlaid. In other words, the changes of the overlay are fixed and are not reapplied to the updated vendor object definition.
Customization of an application frequently involves adding new functionality to existing functionality; for instance, an object may include a default list of groups of people that are allowed to access the object and the modification could be the addition of another group to the list. Customization may also involve subtracting functionality from existing functionality; for instance, the modification may be the removal of a group from the list. When the application is upgraded, it is often desirable that the same change be made to the new version of the application. If during the upgrade of the application the default list of groups with access is changed, the desirable result is the new default list with the same new group being added or removed. This requires that the change be reapplied after the application is altered. As a result, in the known art, changes made to the application must be tracked and recorded independent of the application. After the application is upgraded, the changes must be reapplied to the updated application definition.